Information-Unit Based Scaling of an Ordered Event Stream

ABSTRACT

Scaling an ordered event stream (OES) based on an information-unit (IU) metric is disclosed. The IU metric can correspond to an amount of computing resources that can be consumed to access information embodied in event data of an event of the OES. In this regard, the amount of computing resources to access the data of the stream event itself can be distinct from an amount of computing resources employed to access information embodied in the data. As such, where an external application, e.g., a reader, a writer, etc., can connect to an OES data storage system, enabling the OES to be scaled in response to burdening of computing resources accessing event information, rather than merely event data, can aid in preservation of an ordering of events accessed from the OES.

BACKGROUND

Data can be stored via an ordered event stream data storage system.Conventionally, adapting a topology of an ordered event stream of anordered event stream data storage system can be based on an amount ofdata to be stored by, or read from, an ordered event stream.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is an illustration of an example embodiment that can facilitatescaling of an ordered event stream (OES).

FIG. 2 is an illustration of an example OES topology that can correspondto information-unit based scaling of an example OES embodiment.

FIG. 3 is an illustration of an example embodiment that can facilitateinformation-unit scaling of an OES via reader application feedback.

FIG. 4 is an illustration of one example embodiment facilitatinginformation-unit scaling of for an OES via writer application feedback.

FIG. 5 is an illustration of an example embodiment enablinginformation-unit based scaling of an OES according to example eventinformation content.

FIG. 6 is an illustration of one example embodiment that can facilitateapplying a scaling policy to information-unit scaling of an OES.

FIG. 7 is an illustration of an example embodiment facilitatinginformation-unit scaling of an OES.

FIG. 8 is an illustration of one example embodiment enabling applicationof writer feedback to information-unit scaling of an OES.

FIG. 9 depicts an example schematic block diagram of a computingenvironment with which an embodiment of the disclosed subject matter caninteract.

FIG. 10 illustrates an example block diagram of a computing systemoperable to execute the disclosed systems and methods in accordance withan embodiment.

DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the subject disclosure. It may be evident, however,that the subject disclosure may be practiced without these specificdetails. In other instances, well-known structures and devices are shownin block diagram form in order to facilitate describing the subjectdisclosure.

The disclosed subject matter relates to data storage via an orderedevent stream (OES) data storage system (OES system) and, moreparticularly, to scaling storage regions, e.g., segmentation, OEStopography, etc., of one or more ordered event streams stored by anordered event stream data storage system. Conventional OES systems canbe scaled based on an amount of data to be stored, written, read,accessed, etc., e.g., the OES can be scaled based on a count of the onesand zeros that are to be stored/accessed via an OES of an OES system. Itis noted that the amount of data to be stored/accessed is distinct fromthe amount of information to be stored/accessed. In this regard, anamount of data can embody various amounts of information via the data.As an example, images of the same data size, a first 1-megabyte (MB)image can comprise low amounts of data, such as an image of just a starka white wall, while a second 1 MB image could comprise moderate amountsof information, e.g., an image of just a pair of dice, and a third 1 MBimage can comprise large amounts of data, such as for an image of acrowd of people. As such, the idea of scaling an OES based on an amountof information can be attractive in some OES system embodiments. Whilesome embodiments can continue to benefit from data-based scaling, forexample, where OES events generally contain similar amounts ofinformation, in other embodiments where different OES events cancomprise more varied amounts of information for relatively consistentdata-sizes, information-based scaling can be an attractive alternativescaling metric. Information-based scaling of an OES, or portion thereof,is accordingly disclosed in more detail herein below.

At a basic level, an ordered event stream (OES) can be a durable,elastic, append-only, and potentially unbounded, sequence of events. Anevent can be added to a head of a stream of events, e.g., a first eventcan be considered as residing at a tail of an OES and a most recentevent can be regarded as residing at a head of the OES with other eventsordered between the tail and the head of the OES. It is noted at thispoint that an OES can generally be referred to as a ‘stream,’ ‘eventstream,’ or similar term herein throughout. The events need not bestored in contiguous storage locations to be logically sequenced in anOES, stream representation, etc., e.g., a first event of an OES can bestored on a first disk, a second event of the OES on a remotely locatedsecond disk, and a third event of the OES stored at a further remotethird disk. As such, a stream can be said to logically sequence theexample first, second, and third events by reference to their storeddata in different physical locations, and the OES can be regarded as anabstraction enabling ordering of the events comprised in the stored dataat any physical location(s), e.g., the stored events can be regarded asbeing ordered according to the OES, thereby enabling writing, reading,or other event operations, to occur according to an ordering of theevents embodied in the OES. It is noted that some stream storage systemscan employ an alternative head/tail terminology, for example, a firstevent can be added at a head of an OES, while subsequent new events canthen be added sequentially to a tail of the OES, however, this isindistinguishable in all other ways from the head/tail conventiongenerally employed in the instant disclosure, e.g., an event is stillpart of a sequence of events and corresponds to a key as disclosedelsewhere herein.

Events of a stream can be associated with a routing key, or simply keyfor convenience, typically a hashed routing key. A key can often bederived from data, or information embodied in the data, of the event,e.g., a “machine-id,” “location,” “device type,” “customer number,”“vehicle identifier,” etc., corresponding to information of the event.In one or more embodiments, an event can be associated with a key,however, data yet to be written to an event can be associated with anaccess target value that can be the same value as the key, e.g., theaccess target value can be determined based on the data, or informationembodied in the data, of the event, a characteristic corresponding tothe event to be recorded, etc., such that the access target value can beregarded to be the same as the key. Accordingly, the terms event key,hashed key value, access target value, key, etc., can be usedinterchangeably for convenience, unless the context indicates a morespecific use. In an example, an access target value can correspond todata to be stored in an event and can be derived from data, informationembodied in the data, or some other characteristic(s) corresponding tothe data, such that when the event is stored, the access target valuecan be used as the key associated with storing the event. Similarly, ina read operation, an access target value can be indicated to allowaccess to an event having a key that matches the access target valuebecause the event was written to the OES according to a key that can bethe same as the access target value. Generally speaking, the term accesstarget value can relate to a ‘key's value,’ such that access to eventsof an OES can be based on comparing the access target value to keyvalues for actual stored events, where an existing event is to be read,or key values that will be used to store an event, where an event willbe written into the OES according to the access target value. Again, itcan be generally easier to just use the term key for both access targetvalue and routing key, unless more specificity is needed in an example,and this convention is generally used throughout the instant disclosurefor simplicity and brevity. Events with the same routing key can bewritten to a corresponding stream or stream segment, and can also beconsumed, e.g., read, etc., in the order in which they were written tothe stream or stream segment.

A stream can be comprised of a group of portions, e.g., shards,partitions, pieces, etc., that can generally be referred to as streamsegments, or simply segments for convenience. The segments can act aslogical containers for one or more events within a stream, e.g., it isunderstood that events written to geographically disparate data storagedevices can logically be written to the same stream segment, e.g., samelogical container, according to the instant disclosure. When a new eventis written to a stream, it can be stored to a segment of the streambased on a corresponding key. Event routing keys can form a ‘key space,’‘hashed key space,’ etc. The key space can be employed to divide thestream into a number of parts, e.g., segments. In typical embodiments,consistent hashing can be employed to assign events to appropriatesegments. As an example, where a stream comprises only one segment, allevents to be written to the stream are accordingly written to the samesegment in an ordered manner, wherein this example segment simplycorresponds to the entire key space. As another example, where a streamcomprises two parallel segments, the key space of the event, e.g., fromzero to ‘n’, can be associated with the two segments, however each ofthe two segments can be associated with a portion of the total keyspace, for example, the first segment can store events of time t with akey between zero and ‘m’ and the second segment can store other eventsof time t with a key between ‘m+1’ and ‘n’. This can also be written as,“0<[first segment event keys]<m<[second segment event keys]<n.” It willbe appreciated that more segments can serve to further divide the keyspace such that a segment can store an event with a key falling withinthe range of the key space associated with that segment. As an example,a four-segment event stream can have each segment store data at time tfor a quarter of the total key space, e.g., segment A can store eventswith keys from 0 to <0.25, segment B can store events with keys from0.25 to <0.5, segment C can store events with keys from 0.5 to <0.75,and segment D can store events with keys from 0.75 to 1.0.

In one or more embodiments, a segment of an event stream can typicallybe associated with a single processing instance, e.g., one processor,one cooperating group of processors, etc., to assure ordering of theevents stored in the segment. A processing instance can be a single realphysical processor, a virtualized processor instance executing on one ormore real physical processors, a group of real physical processors, agroup of virtual processor instances executing on one or more realphysical processors, etc. As an example, a processing instance can beembodied via a blade server in a computing facility. As another example,a processing instance can be a virtual processor deployed in an elasticcomputing system, e.g., a ‘cloud server,’ etc. Typically, a processinginstance can be associated with a level of performance which, in someembodiments, can be measured via one or more key performance indicators(KPIs) for the processing instance. As an example, a first blade servercan have a first level of performance and a second blade server can havea second level of performance. In this example, where the two bladeservers can comprise similar hardware and environments, they can havesimilar levels of performance. However, also in this example, where thetwo blade servers comprise different hardware and/or are in differentenvironments, they can have different, sometimes substantiallydifferent, levels of performance. As an example, a first processinginstance can perform one unit of work, a second processing instance canperform one unit of work, a third processing instance can perform fiveunits of work, a fourth processing instances can perform three units ofwork, etc., where the unit of work can correspond to a number of eventstream operations that can be performed by the processing instances,e.g., reads, writes, etc. In this example, the first and secondprocessing instances can perform similar amounts of work in an eventstream storage system, while the third processing instance can becapable of up to five times the work of either the first or secondprocessing instance.

Generally, the computing resources of a processing instance can beassociated with costs, e.g., monetary costs, electrical consumptioncosts, dispersion of generated heat costs, support costs, real estatefor deployment costs, operations per unit time as a cost, etc. Computingresources can further comprise computer memory, computer storage,network access, virtual computer resource access, etc. Therefore,generally, selecting an appropriate processing instance, or othercomputing resource, can be associated with optimizing various costs. Asan example, if an event stream typically consumes less than one unit ofwork, then pairing the stream with a processing instance that canperform one unit of work can be deemed a better use of computingresources, e.g., lower overall aggregate costs, etc., than pairing theevent stream with a processing instance that can perform 200 units ofwork which can result in wasting up to 199 units of work throughunderutilization. Moreover, in this example, the 200-unit processinginstance, for example, can be a newer high end processing instance thatcan have a high monetary cost, and generate more heat than the one-unitprocessing instance that, for example, can be a low-cost commodityprocessing instance that is plentiful, has a low monetary cost, and isalready widely deployed. As such, paring the one unit of work eventstream with a racecar of a performance instance can be understood aspossibly not being an optimal pairing in comparison to a more pedestrianperformance processing instance.

In various embodiments described herein, scaling technology employed ina stream data storage system can improve a stream data storage system,such as by scaling an OES to comprise one or more segments that canimprove use of computing resources in contrast to a conventionalunscaled stream data storage system. In one or more example embodiments,a portion of a stream, e.g., an OES or portion thereof, can be dividedevenly to distribute the work corresponding to event operations, e.g.,splitting a stream in to two subsequent similar portions can, forexample, enable use of two processors in parallel rather than oneprocessor. This can be regarded as a form of ‘symmetrical scaling’ of anevent stream. Alternatively, a stream can be split into dissimilarportions, regarded as a form of ‘asymmetrical scaling,’ that can resultin portions that are dissimilar, e.g., one resulting segment cancorrespond to a greater or lesser key space than a second resultingsegment, etc. In some embodiments, symmetric and asymmetric scaling canbe performed on one portion of an OES and can result in two or moresubsequent other portions of the OES, for example, symmetrical scalingof a stream into three or more similar portions, etc. In one or moreembodiments, these other portions can also comprise a mix of symmetricand asymmetric splits of the stream, for example, a first portion of astream can be split into a second, third, and fourth portion, whereinthe second and third can be similar, e.g., symmetric, and the fourthportion can be dissimilar from the second or third portion, e.g.,asymmetric. In this example, the scaling can be referred to as ‘mixedscaling,’ e.g., implying that the subsequent portions of the streamafter scaling can comprise a mix of symmetric and asymmetric portions,see the various example symmetric scaling changes to segments of anexample OES illustrated in FIG. 2.

Scaling of the event stream can be in response to a thresholdconsumption of computing resources, e.g., when a threshold work level istraversed, an event stream can be scaled. In one or more embodiments,scaling can generally be associated with allocating computing operationsto logical portions of an ordered stream of events. As an illustrativeexample, first processor(s) can satisfactorily write 5000 events perunit time to an ordered event stream, e.g., into storage correspondingto the ordered event stream, however, where the rate of events to bewritten to the stream, for example, doubles to 10000 events per unittime, the first processor(s) can be determined to be underperforming dueto being overly burdened and it can be desirable to scale the OES tocompensate for overburdening of the first processor(s). As such, scalingcan add second processor(s) such that the load on the first, and now thesecond, processors can be similar, e.g., the writing of the example10000 events per unit time can be managed by two or more processor afterthe scaling rather than just the first processor(s) before the scalingof the OES. As noted elsewhere herein, the scaling can be symmetric,asymmetric, or mixed scaling. It can be further noted that symmetricscaling of a key space can result in non-symmetric loading of acomputing resource(s). As an expansion of a previous example, where afirst processor(s) writes 5000 events per unit time to event keysbetween 0 and 0.5 of a key space, and this load doubles as a result ofan additional 5000 writes with an event key between 0 and 0.1 of the keyspace, then scaling the OES by symmetrically dividing the key spacebetween the first processor(s) from 0 to 0.25 and the secondprocessor(s) from 0.25 to 0.5 of the key space should not result in asymmetric division of computer resource loading, e.g., the firstprocessor(s) would now address a portion of the initial 5000 events andan additional burden from the 5000 events between 0 and 0.1 of the keyspace, while the second processor(s) would address the initial 5000events less the portion still being managed by the first processor(s),but would not get any part of the additional 5000 events. As such, mereequal key space division of a portion of an OES that is ignorant of thedistribution of work across the key space of the event stream can beless effective that might otherwise be imagined. Improved scalingtechnologies can be considerate of a resulting workload and can, forexample, accommodate asymmetric scaling of a portion of an OES based ona key space characteristic(s), such that resulting workloads can bedistributed to available computing resources in a more tailored manner,e.g., a scaling vent can have asymmetric key space scaling that canresult in symmetric computing resource use, etc. Moreover, advancedscaling techniques can perform scaling intelligently, e.g., based onindications received from a user, administrator, analytics component,optimization engine, etc., to selectively burden a portion(s) ofavailable computing resources according to a performance, capability,metric, etc., of an individual portion(s) of the available resources,e.g., adding an additional mid-range processor can result in a differentscaling than adding another high-end processor. Optionally, scaling canalso be selectively deferred, wherein the deferral can reduceconsumption of computing resources, e.g., committing a scaling event canconsume computing resources so it can be desirable to scale in responseto determining that the scaling would beneficial over and above any useof computing resources to commit the scaling event itself.

The general discussion of scaling can be examined with more nuance.Where events can be of similar data size, e.g., events can consume asimilar amount of computing resources to write, read, move, etc., thenthis can suggest that where computing resources remain adequatelyburdened, then there can be no impetus to scale an OES. However, ifcomputing resource demands beyond the edges of an OES system areconsidered, there can be benefits to scaling the OES even where thedata-size of events and volume of events can remain relativelyconsistent. As an example, where a reader application receives eventdata read from an OES, and where the amount of information embodied inthe received event data can vary, this variable amount of informationcan, in some embodiments, tax the computing resources associated withthe reader application. In this example, the reader application devicescan become overburdened via attempting to extract information from astream of data that can be relatively consistent in size. This couldhappen, for example, where a stream reads video frames to video readerapplication that extracts identities of persons in the video framesread. In this example, where there are no faces in first video frames,then there can be substantially less reader processing than for secondvideo frames that can comprise many faces. Where there are many faces,the computing resources of the example reader application can be muchmore burdened and it can be appropriate to scale the OES to allow foradditional reader application instances to be implemented, each readingevents from a narrower key space region. This can serve to preserveevent ordering while also allowing a reduced event reading rate perreader application to counterbalance high computing resource demands onsome reader applications. Similarly, where the count of faces drops inthe example, the OES can be scaled down to present fewer segments thatcan correspond with fewer reader applications. This can be understood toillustrate scaling by an amount of information, e.g., aninformation-unit, rather than by an amount of data. Accordingly, an OEScan be scaled in regard to data, information, or combinations thereof.It is noted that other scaling metrics can also be employed withoutdeparting from the scope of the instant disclosure, but these othermetrics are beyond the scope of the instant disclosure and are thereforenot further discussed herein.

Embodiments can employ information-based scaling, data-based scaling, orscaling based on other metrics. As is disclosed elsewhere herein,information can be represented by data of an event, e.g., the data ofthe event can be the binary data that is stored as the event, while theinformation, in contrast, can be information represented in the data. Itcan be readily appreciated with events of a same data size can comprisevastly different amounts of information, for example, by employingcompression technology to fit more information in a given amount ofdata. Moreover, extraction of information from data can consumedifferent amounts of computing resources. Typically, the term‘information-unit’ can indicate a first amount of computing resourcesthat can be consumed in accessing information embodied in event data. Assuch, an event that is two information units (IUs) can consume twice thecomputing resources to access the information embodied in a unit of dataas for a one IU event. This concept can extend to determining that afour IU event that is two data units in size comprises double theinformation per data unit of a one IU event that is one data unit insize, e.g., 4 IU/2 DU=2×(1 IU/1 DU). Accordingly, scaling an OES basedon IUs can reflect an amount of computing resources that can be consumedto access information embodied in event data. In an embodiment, feedbackfrom read applications indicating computing resource usage to accessinformation from event data can be employed to scale an OES. In someembodiments, OES scaling can be applied after an event is written, e.g.,the topology of an OES can be scaled based on reader applicationfeedback related to an IU metric after events have been written. In thisembodiment, for instance, reading events days after they were writtencan result in scaling the OES based on IU metrics. In additional,historic IU determinations can be employed in scaling an OES at eventwriting. In these embodiments, for example, analysis of an event, e.g.,prior to writing, in regard to other historically written events of asimilar type, etc., can reflect a more linear relationship between anamount of data and an amount of information, such that the amount ofdata can be used as an indicator of an amount of information, therebyallowing scaling of the OES when writing events. Furthermore, inembodiments scaling at event writing, the event data can be analyzedbefore writing to explicitly determine an IU metric that can then beemployed in scaling the OES when writing the corresponding event. Theseembodiments can be viewed as preprocessing data of an event to bewritten to extract IU metrics to facilitate writing the event in acorrespondingly scaled OES. In some of these embodiments, less than allevents can be preprocessed, e.g., a random sampling of events, periodicevents, etc., can be selected for preprocessing to determine an IUmetric that can be applied to OES scaling when writing events.

To the accomplishment of the foregoing and related ends, the disclosedsubject matter, then, comprises one or more of the features hereinaftermore fully described. The following description and the annexed drawingsset forth in detail certain illustrative characteristics of the subjectmatter. However, these characteristics are indicative of but a few ofthe various ways in which the principles of the subject matter can beemployed. Other characteristics, advantages, and novel features of thedisclosed subject matter will become apparent from the followingdetailed description when considered in conjunction with the provideddrawings.

FIG. 1 is an illustration of a system 100, which can facilitate scalingof an ordered event stream (OES), in accordance with one or moreembodiments of the subject disclosure. System 100 can comprise a storagecomponent 102 that can store one or more OESs, e.g., OES 110, etc.Generally, OES 110 can store one or more events. An event is associatedwith a key, e.g., a routing key. A key can typically be determined fromcharacteristics of the corresponding event, although other keydetermination techniques can be employed. As an example, a key can bebased on a characteristic of the source of the event data, such as acustomer identifier, machine identifier, a location of a deviceproviding the event data, a type of a device providing the event data,etc. Events with a same key can be written into OES 110 in an orderedmanner according to the key. Similarly, events with a same key can beread from OES 110 in an ordered manner, e.g., in the order they werepreviously written into OES 110. Components providing events to bewritten can be termed ‘writers’ and components requesting events can betermed ‘readers.’ As such, a writer can provide an event that can bewritten to OES 110 in an ordered manner based on a key associated withthe event. Similarly, a reader can receive an event from OES 110 basedon a key.

Processor component 104 of a system 100 can receive write(s) 106 thatcan be written to OES 110 stored on storage component 102, e.g.,write(s) 106 can be received from a writer application instance, etc.Processor component 104 of a system 100 can provide access to events ofOES 110 based on a key, e.g., as read(s) 107 that can be communicated toa reader, e.g., read(s) 107 can be facilitated for a reader applicationinstance, etc. Generally, one processing instance, e.g., processorcomponent 104, etc., is designated for writing events to a portion,e.g., segment, of OES 110. OES 110 can comprise one segment and/orparallel segments, e.g., stream segments, etc., that can store eventsaccording to a key. In an example embodiment, more than one processinginstance writing to a single segment of an OES can typically bedisfavored because it can increase the difficulty of writing incomingevents in an ordered manner. However, a given processing instance canread/write to more than one OES segment, e.g., a given processinginstance can write to one or more OESs, to one or more segments of oneOES, to one or more segments of one or more OESs, etc. In an exampleembodiment, while more than one processing instance writing to a segmentof an OES is typically disfavored, more than one processing instancereading from a segment can be fully supported, encouraged, etc. As such,for a given number of segments, in some embodiments, there can be up tothe same number of processing instances, e.g., to limit more than oneprocessor instance writing to a segment. Although adding more processinginstances can be allowable, for example to increase read operations,these additional processing instances can be constrained to readoperations to limit the possibility of scrambling an order of eventsbeing written to a segment. It is further noted that system 100 cancomprise idle processing instances that are not reading or writing tothe OES, for example, as reserve processing instances supportingfailover operations protecting against an active processing instancebecoming less responsive, in support of scaling events, etc. In one ormore embodiments, keys of one or more segments of an OES can represent akey space for OES 110. Segments can therefore act as logical containersassociated with a particular range of keys for a portion of an eventstream and can be used to store events of OES 110. When a new event iswritten to a stream, it can be logically stored to a segment based onthe event key regardless of where it is physically stored. In an exampleembodiment, the key space can be divided into a number of ranges thatcan correspond to the number of segments comprising an OES, e.g., OES110. As an example, a key space for an OES can be from 0 to 100, the OEScan comprise two parallel segments wherein the first segment cansequentially store events with, for example, keys from 0 to 30, and thesecond segment can sequentially store events with keys from >30 to 100.In this example, a first event with a key of 54 can be appended to thesecond segment, a second event with a key of 29 can be appended to thefirst segment, a third event with a key of 14 can be further appended tothe first segment after the second event, etc. In an example embodiment,storage component 102 can store one or more OESs, although only OES 110is illustrated for clarity and brevity.

OES 110, as illustrated in system 100, can be an overly simplisticexample of an OES that can comprise just one segment for storingincoming event write(s) 106 and sourcing event read(s) 107, andtherefore the key space of OES 110 can be embodied in the illustratedsingle segment of events, e.g., the key space of OES 110 is notillustrated as being distributed across more than one parallel eventstorage segment. OES 110 can have an origin terminus 112. Whereas thereader of this document is expected to understand that the OESrepresents a logical ordering of events actually stored on physicalstorage devices, the instant disclosure will generally simply refer tologically writing to an OES as writing to an OES for the sake ofbrevity. A first event can be written at origin terminus 112. Thesubsequent events can then be appended at an additive terminus 114 thatis typically always at the head of the stream of written ordered events,e.g., a most recent event is written to the head of OES 110, whichprovides ordering of the events being written. This results in OES 110allowing for continuous and unbounded data storage that can be adurable, elastic, append-only, unbounded sequence of events, e.g., anOES can logically represent events stored at any number of physicalstorage locations, e.g., spanning files, spanning disks, spanning datacenters, etc. In an example, a (K+1)^(th) event can be appended to theK^(th) event of OES 110 at additive terminus 114. In an embodiment,storage component 102 can store any number of OESs. Moreover, any oneOES can comprise any number of parallel segments, e.g., stings of eventsfor a defined key space range. Each segment can comprise an orderedsequence of stored events.

In system 100, information-unit scaling component (IUSC) 120 canfacilitate OES scaling based on an IU metric. In an embodiment, an IUmetric can represent an amount of computing resources that can beconsumed to access information represented in data of an event. In thisregard, some events can comprise more information per unit of eventdata, some events can consume more computing resources to access anamount of information embodied in event data, etc. Accordingly, evenwhere reading event data itself may not necessarily overburden computingresources of an OES system, IU metrics can indicate that othercomponents of, or components in communication with, an OES system can besufficiently burdened so as to benefit from the OES system scaling anOES to allow properly ordered access to events, e.g., according todifferent key space topologies of corresponding OES epochs. As anexample, where events of a stream are one unit of data in size, andbetween t1 and t2 each event embodies information that can consume 10units of computing resources to access, while between t2 and t3 eachevent can consume 150 units of computing resources to access embodiedinformation, then where a reader can supply up to 80 units of computingresources to extract information from the event data, the reader can bemore than adequate between t1 and t2 but be overburdened between t2 andt3. In this example, an OES system can experience the same datathroughput between t1 and t2 as between t2 and t3, e.g., the event dataremains at one data unit per event. As such, in this example, the IUvalue can go from 10 to 150 while the data unit (DU) can remain at 1.Accordingly, it is noted that between t2 and t3, the reader can beoverburdened, which can be managed in numerous ways, e.g., bufferingread out event data, adding processors that may compromise the read-outordering of the events, etc. However, an alternative can be to signalthe OES system that the reader is above a threshold IU value such thatthe OES system can scale the OES to divide the read-out events into two(or more) segments that can then be, for example, read by two readers ina manner that can preserve event ordering.

Continuing the above example, when events write(s) 106 are received,IUSC 120 can facilitate preprocessing one or more write(s) 106 prior tothose write(s) being committed to OES 110. The preprocessing canemulate, simulate, perform an analysis based on a model of, etc., anindicated reader application to determine a predicted IU value that canthen be employed in scaling OES 110 when writing the corresponding eventthereto. In some embodiments one, some or all write(s) 106 can bepreprocessed in regard to OES scaling. In these embodiments, differencesbetween an indicated reader application and an eventual actual readerapplication can result in mismatches in any corresponding OES scaling,e.g., if the writing is performed according to a predicted IU value fora reader application executing on a rudimentary computing platform andthen the OES is later read by a reader application executing on asupercomputer platform, the scaling of the OES at writing can be quitefar removed from scaling that would have been more appropriate at thetime of reading the OES. As such, reader application feedback can stillbe employed in conjunction with write time OES scaling based on IUmetrics. In these embodiments, scaling at the time of writing can thenbe compensated for at the time of reading by further OES scaling.

FIG. 2 is an illustration of an example OES topology that can correspondto information-unit based scaling of an example OES embodiment, inaccordance with one or more embodiments of the subject disclosure.Generally, an OES can comprise segments corresponding to a key spacetopology, e.g., key space 200, etc. At a first time, for example t1, keyspace 200 can correspond to one or more parallel segments, e.g., segment1, segment 2, segment 3, etc. At some point a segment of thecorresponding OES can be scaled. As an example, at t2, segment 1 can bescaled up. This can result in causing segment 4 and segment 5 in keyspace 200 and correspondingly sealing segment 1 therein. The topology ofthe OES comprising segments 1-3 and the corresponding key space up totime t1, can be designated as epoch 1. Similarly, the topology of theOES comprising segments 4-5 and 2-3, and the corresponding key spacebetween t1 and t2, can be designated as epoch 2, etc. It is noted thatthe close relationship between segment(s) of an OES and thecorresponding portions of a key space of the OES can often result inmixing of the terms ‘OES’ and ‘key space,’ e.g., key space 200 can oftenbe referred to as ‘OES 200’ for the sake of brevity. Such notedconventions are used hereinbelow for the sake of brevity, e.g., keyspace 200 can be referred to as and OES 200 hereinbelow even where suchnomenclature is technically less correct, unless implicitly orexplicitly indicated otherwise, e.g., the reader of this disclosure isexpected to appreciate the tight coupling between a key space and thecorresponding OES is such that it is less wordy to simply refer to keyspace 200 as illustrating the logical arrangement of OES segments as‘OES 200.’

In an example embodiment, segments 2 and 3 can be continuous acrossepochs 1 and 2 while segment 1 can end at the transition from epoch 1 to2. In an example embodiment, in epoch 1, events associated with a keybetween 0.5 and 1, e.g., 0.5>key≥1, can be written (and read from)segment 1, while in epoch 2, events associated with a key between 0.75and 1, e.g., 0.75>key≥1.0, can be written (and read from) segment 4 andevents associated with a key between 0.5 and 0.75, e.g., 0.5>key≥0.75,can be written (and read from) segment 5. As such, access to events fora given key can be associated with reads in different epochs. As anexample, reading an event with a key of 0.8 can read from both segment 1and segment 4. Where the read is from head to tail, the read of exampleevents with a key of 0.8 can begin reading in segment 4 and thencontinue reading into segment 1 across the epoch boundary between epoch2 and 1. Similarly, where the read is from tail to head, eventsassociated with the example key of 0.8 can begin in segment 1 andcontinue into segment 4 across the epoch boundary. However, it is notedthat generally no additional events are written into segment 1 after thescaling event is committed and a new epoch is begun.

In epoch 2, the topology of OES 200 can comprise segments 4-5 and 2-3.At some point further scaling can be undertaken, e.g., at t3. OES 200can, for example, scale down by condensing segment 2 and 5 into segment6 at t3. This example scaling down can reduce a count of segmentscomprising OES 200. The scaling at t3 can result in ending epoch 2 andbeginning epoch 3. The example scaling can cayuse segment 6 and canclose segments 2 and 5. As such, in epoch 3, the topology of the OEScomprising segments 3-4 and 6 post-scaling can distribute the key spaceof OES 200, for example, as 0≤segment 3>0.25, 0.25>segment 6≥0.75, and0.75>segment 4≥1.0.

In an example embodiment, scaling of segment 1 into segments 4 and 5between epoch 1 and epoch 2 can be related to a change in IU values forevents of segment 1. In this example embodiment, an IUSC, e.g., IUSC120, etc., can determine that a greater amount of computing resources isbeing consumed to access information for events of segment 1 and thetopology of that segment of the OES can be scaled to divide the keyspace to enable an additional processing instance to access data in anordered manner. In this example embodiment, a reader application can beoverburdened in accessing information of events of segment 1 and can,for example, fall behind readers of other segments. By scaling segment 1into segments 4 and 5, a reader application can be applied to eachresulting scaled segment and can reduce a number of events beingprocessed without loss of event order. In this example, cutting thenumber of events in half can reduce the consumption of computingresources by each reader application below an acceptable threshold.

In another example, segments 5 and 2 can be condensed into segment 6where the demand on reader applications for segments 5 and 2 fall belowa threshold. This can enable an OES system corresponding to key space200, to be more efficient by not underutilizing computing resourcesrelated to reading out events.

In some embodiments, preprocessing can be employed to scale segments ofthe example OES key space 200 at the time of writing events to the OES.Moreover, at the time of reading, supplemental scaling can be applied toalter the topology of the OES where an estimated IU metric at the timeof writing the event can be sufficiently dissimilar to an IU metric atthe time of reading events from the OES. Furthermore, whereas more thanone reader application instance, e.g., of one or more readerapplications, can read the same OES data, scaling for one readerapplication instance can impact other reader application instances,however, this can be addressed by applying a scaling policy, for exampleas discussed in regard to scaling policy component 622, etc., elsewhereherein.

FIG. 3 is an illustration of a system 300, which can facilitateinformation-unit scaling of an OES via reader application feedback, inaccordance with embodiments of the subject disclosure. System 300 cancomprise OES 310 that can store one or more OES events. OES 310 canstore events based on write(s) 306 received by processor component 304.OES 310 can facilitate access to stored events as read(s) 307 viaprocessor 304. OES 310 can be stored via an OES data storage system,e.g., example system 100, etc., on a storage component, e.g., storagecomponent 102, etc. Write(s) 306 can be received from a writerapplication instance. A writer application instance can be embodied incomponents external to, but in communication with, system 300.Similarly, read(s) 307 can be communicated to a reader applicationinstance, which in some embodiments, can be embodied in componentsexternal to, but in communication with, system 300. A writer applicationinstance, hereinafter generally referred to as a writer, or othersimilar term, can be one or more writer application, e.g., a group ofwriter applications can be considered a writer application instance. Areader application instance, herein generally referred to as a reader,or other similar term, can be one or more reader application, e.g., agroup of reader applications can be considered a reader applicationinstance.

IUSC 320 can interact with processor component 304 of system 300 tofacilitate information-based scaling of OES 310 or a portion thereof.IUSC 320 can receive reader application feedback 309. Reader applicationfeedback 309 can indicate an IU metric, e.g., an indication of eventprocessing computing resource demand, in terms of information unitvalues, for one or more reader application instances. As is notedelsewhere herein, a measurement of burden on computing resources toenable accessing information embodied in an event, e.g., aninformation-unit metric, can be distinct from a measurement of the sizeof an event in terms of bits, e.g., a data-unit metric. As an example,where a reader application instance reads events that can each be onedata unit in size, the reader application instance can experiencedifferent computing resource demands to access information embodied inthe data of the event. In this example, the events can store image datathat facial recognition can be performed upon. Where a first exampleevent can comprise few faces against a uniform background, theextraction of facial recognition information can demand relatively fewercomputing resources than a second example event that can comprise manyfaces against a complex background, event where the first and the secondevents can be of the same or similar data-unit sizes. Accordingly, inthis example, where a reader can be much more highly taxed by eventssimilar to the second example event than for events similar to the firstexample event, IUSC 320 can facilitate scaling OES 310 accordingly.

IUSC 320 can comprise reader performance component 329 that can enableOES scaling based on reader application feedback 309. Reader performancecomponent 329 can determine performance(s) of reader(s) reading from OES310, or a portion thereof, in terms of IU metrics. In an embodiment,reader performance component 329 can determine IU performance fordistinct and different readers of OES 310, for example, OES 310 can be astream of images from several cameras facing stairwells into a trainstation in a metropolitan area, which OES can be, for example, accessedby readers from a transportation management system counting people inimages, from a law enforcement facial recognition monitoring system,from an educational research institute studying traffic patterns basedon a count of changing image pixels, etc., e.g., the same OES can beaccessed by readers of one or more distinct reader instances.

Available computing resources of these different reader instances can bethe same in some embodiments, but more typically can be dissimilar,e.g., the example law enforcement reader can be hugely powerful incomparison to the example educational institution reader instancebecause the law enforcement agency can have a much larger budget toapply to the corresponding reader. Moreover, the information beingextracted from the same data can be different for different readerapplication instances, e.g., different readers can extract differentinformation from the same event data. In this regard, reader performancecomponent 329 can enable determining IU values for the several differentreaders in the preceding example. Moreover, IUSC 320 can then scale OES310 based on these several different determined IU values, resulting inthe different reader instances experiencing read(s) 307 under differentIU values. Continuing the example, the IU value of the law enforcementreader can be relatively low in contrast to the educational reader whenthere are few people imaged on the example stairways, as a firstscenario, which can be due to there being few faces to extract and thelaw enforcement reader having a large amount of computing resourcescompared to the educational reader. However, as the first scenarioevolves into a second scenario for this example, as the number of peoplein the images of the stairs starts to increase, such as near peakcommute times for the train station, the IU value of the law enforcementreader can indicate that the example substantial law enforcement readercomputing resources are relatively more taxed than the educationalreader, which can be due to the shear number of facial recognitions thatthe law enforcement reader can be tasked with per event image, a loadnot experienced by the educational reader in this example.

In these example scenarios, IUSC 320, if determined to be appropriate,can scale OES 310 to accommodate the education reader in the firstscenario because the loading of the educational reader can be moreaffected than the law enforcement reader due to the example sheardifference in available computing resources. Then, in this example, whenthe second scenario is experienced, IUSC 320 can alter the scaling ofOES 310, again if determined to be appropriate, to support the lawenforcement reader which can now be more heavily taxed than theeducational reader. As such, while the amount of data, e.g., thedata-unit, of the events of OES 310 can be relatively static in theabove example, the information-unit values can change as a reflection ofhow demanding information extraction is for a given reader under someset of circumstances. This IU metric can therefore support OES scalingbased on reader feedback of reader performance. The example OES, forexample, can store four camera feeds. The OES of this example can bescaled to comprise two segments, each having two camera feeds. Thisexample scaling can therefore transition from providing the lawenforcement reader a single stream segment with events from four camerasto two stream segments each with events of two cameras. Where, in thisexample, the number of facial recognition events is about event acrossthe camera feeds, then the law enforcement entity can add an additionalreader, such that there can be two law enforcement readers each readingone segment, effectively doubling the processing power of the lawenforcement system in this example. It is noted that where peak trafficpasses and the facial recognition demand drops, this can be reflected inan IU of a third example scenario corresponding to IUSC 320 scaling OES310 to reduce a number of segments, e.g., scaling down where the demandon computing resources of the law enforcement readers has reverted whichcan result in the example OES returning to one segment of four camerafeeds, etc.

FIG. 4 is an illustration of a system 400 that can enableinformation-unit scaling of for an OES via writer application feedback,in accordance with embodiments of the subject disclosure. System 400 cancomprise OES 410 that can store one or more OES events. OES 410 canstore events based on write(s) 406 received by processor component 404.OES 410 can facilitate access to stored events as read(s) 407 viaprocessor 404. OES 410 can be stored via an OES data storage system,e.g., example system 100, 200, etc., on a storage component, e.g.,storage component 102, etc. Write(s) 406 can be received from a writerapplication instance. A writer application instance can be embodied incomponents external to, but in communication with, system 400.Similarly, read(s) 407 can be communicated to a reader applicationinstance, which in some embodiments, can be embodied in componentsexternal to, but in communication with, system 400. A writer applicationinstance, hereinafter generally referred to as a writer, or othersimilar term, can be one or more writer application, e.g., a group ofwriter applications can be considered a writer application instance. Areader application instance, herein generally referred to as a reader,or other similar term, can be one or more reader application, e.g., agroup of reader applications can be considered a reader applicationinstance.

IUSC 420 can interact with processor component 404 of system 400 tofacilitate information-based scaling of OES 410, or a portion thereof.IUSC 420 can determine writer application feedback 408 based on data tobe written to an event, e.g., received via write(s) 406, wherein writerapplication feedback 408 can enable scaling of OES 410 prior to writingthe corresponding event. In this regard, IUSC 420 can comprise writerperformance component 428 that can receive event data, e.g., via aportion of event data comprised in write(s) 406, etc., and can determinescaling of OES 410 based on the received event data prior to writing acorresponding event. Writer performance component 428 can thereforedetermine an IU value for an event prior to writing the event to OES410. As such, OES 410 can be appropriately scaled based on thedetermined IU value prior to writing the event. Writer performancecomponent 428 can determine the IU based on applying a model of a readerto the received event data, e.g., analyzing modeled reader performance,emulation of a reader, simulation of a reader, etc., to determine an IUvalue that can be employed by IUSC 420 to indicate scaling of OES 410prior to writing the analyzed received event data. Again, the scaling ofthe OES can e based on IU, rather than DU, metrics.

In an embodiment, writer performance component 428 can perform analysis,emulation, simulation, modeling, etc., based on updateable readerinformation. The updatable reader information can comprise a defaultreader value, e.g., a default read model, reader emulation, readersimulation, etc. Further, the updateable reader information can compriseone or more other reader value(s), e.g., a library of reader models,emulations, simulations, etc., can be stored to enable determiningvarious IU values based on different reader instances. In someembodiments, IUSC 420 can receive reader application feedback 409 thatcan indicate which readers are reading events from OES 410, and theindication of which readers are reading can be employed by writerperformance component 428 to select an appropriate model, emulation,simulation, etc., upon which to perform incoming event analysis inrelation to scaling OES 410. In an embodiment, writer performancecomponent 428 can employ a history of which readers are reading from OES410 to predict which readers will read from OES in the future, such thatan appropriate reader value can be employed in analysis of incomingevent data to determine scaling of the OES prior to writingcorresponding events. As an example, there can be a first-type and asecond-type reader emulation employed by writer performance component428. In this example, reader application feedback 409 can indicate thatonly the first-type reader has been detected reading events from theOES. Accordingly, in this example, IU-based scaling determinations ofIUSC 420 can be based on writer performance component 428 using thefirst-type reader emulation when analyzing incoming event data comprisedin write(s) 406. IUSC 420 can then generate writer application feedback408 to reflect the performed first-type reader analysis, which writerapplication feedback 408 can be employed to accordingly scale OES 410prior to writing an event based on the received event data analyzedaccording to the first-type reader emulation. As an expansion of thisexample, where historically on the last day of a given month second-typereaders are indicated as reading OES 410, as can be indicated via readerapplication feedback 409, then analysis of incoming event data can beperformed according to the second-type reader emulation by writerperformance component 428. As some embodiments of this example, theanalysis of incoming event data can be performed according to thesecond-type reader emulation, the first-type reader emulation, somecombination thereof, or via another selected reader emulation, by writerperformance component 428.

Example system 400 can differ from example system 300 in that scalingcan be performed proximate to writing events in system 400 and proximateto reading events in system 300. However, even in system 400, IUSC 420can perform read-proximate OES scaling. Whereas scaling proximate towriting an event can embody a predicted further read performance, thescaling can be inaccurate, for example, a scaling proximate to writingcan be based on a reader model that has become stale in the time betweenthe writing and the reading of the events, other reader instances can bereading from the OES that were not predicted in the analysis relating toscaling proximate to writing, etc. As such, preprocessing of write(s)406 to determine OES scaling before writing the corresponding events canbe useful in many circumstances, but even where not ideal, furthercompensating scaling of the OES proximate to reading can be employed. Assuch, while not explicitly illustrated in system 400, IUSC 420 canfurther comprise a reader performance component, e.g., a readerperformance component that can be the same as, or similar to, readerperformance component 329.

FIG. 5 is an illustration of a system 500, which can facilitate enablinginformation-unit based scaling of an OES according to example eventinformation content, in accordance with embodiments of the subjectdisclosure. System 500 can comprise OES 510 that can store one or moreOES events. OES 510 can store events based on write(s) 506 received byprocessor component 504. OES 510 can facilitate access to stored eventsas read(s) 507 via processor 504. OES 510 can be stored via an OES datastorage system, e.g., example system 100, 300, 400, etc., on a storagecomponent, e.g., storage component 102, etc. Write(s) 506 can bereceived from a writer application instance. A writer applicationinstance can be embodied in components external to, but in communicationwith, system 500. Similarly, read(s) 507 can be communicated to a readerapplication instance, which in some embodiments, can be embodied incomponents external to, but in communication with, system 500. A writerapplication instance, hereinafter generally referred to as a writer, orother similar term, can be one or more writer application, e.g., a groupof writer applications can be considered a writer application instance.A reader application instance, herein generally referred to as a reader,or other similar term, can be one or more reader application, e.g., agroup of reader applications can be considered a reader applicationinstance.

IUSC 520 can interact with processor component 504 of system 500 tofacilitate information-based scaling of OES 510 or a portion thereof.IUSC 520 can receive reader application feedback 509. Reader applicationfeedback 509 can indicate an IU metric for one or more readerapplication instances. As is noted elsewhere herein, a measurement of aburden on computing resources to enable accessing information embodiedin an event, e.g., an information-unit metric, can be distinct from ameasurement of the size of an event in terms of bits, e.g., a data-unitmetric. IUSC 520 can comprise reader performance component 529 that canenable OES scaling based on reader application feedback 509. Readerperformance component 529 can determine performance(s) of reader(s)reading from OES 510, or a portion thereof, in terms of IU metrics.Moreover, IUSC 420 can determine writer application feedback 508 basedon data to be written to an event, e.g., received via write(s) 506,wherein writer application feedback 508 can enable scaling of OES 510prior to writing the corresponding event. In this regard, IUSC 520 cancomprise writer performance component 528 that can receive event data,e.g., via a portion of event data comprised in write(s) 506, etc., andcan determine scaling of OES 510 based on the received event data priorto writing a corresponding event. Writer performance component 528 cantherefore determine an IU value for an event prior to writing the eventto OES 510. As such, OES 510 can be appropriately scaled based on thedetermined IU value prior to writing the event. Writer performancecomponent 528 can perform analysis, emulation, simulation, modeling,etc., based on updateable reader information to determine IU valuesemployable in scaling of OES 510 proximate to writing an event. In someembodiments, reader application feedback 509 can indicate which readers,or which types of readers, are reading events from OES 510, and theindication can be employed by writer performance component 528 to selectan appropriate model, emulation, simulation, etc., upon which to performincoming event analysis in relation to scaling OES 510.

In an embodiment, IUSC 520 can determine scaling of OES 510 based on IUsdetermined for information comprised in event data in accord withexample key space 501. At 512, key space 501 can comprise one segment,e.g., in epoch 1, across Interval-1 and Interval-2, e.g., from t1 to t3.Events with keys between 0 and n can be written to and read from OESsegment 512. For example, key space 501, an embodiment of system 500 canscale OES 510 in response to use of computing resources that can belinearly based on a count of figures represented in event data, e.g., atInterval-1 there can be four figures represented in the event data,while in Interval-2 there can be eight figures represented in the eventdata. In this example, the number of figures can be used as the IU valuesimply for the sake of illustration, e.g., in Interval-1 the IU valuecan be 4 and in Interval-2 the IU value can be 8. In this example, aselectable IU threshold for IUSC 520 can be set to scale for IU>7. In anembodiment, the IU values of a segment can be determined by IUSC 520based on reader application feedback 509, e.g., at t2, RPC 529 canemploy reader application feedback 509 to determine that the IU forInterval-1 was equal to 4, etc. Accordingly, at t3 of 501, segment 512can be scaled into segments 514 and 515. Continuing this example, at t4,RPC 529 can employ reader application feedback 509 to determine that theIU for Interval-3 for segment 514 was equal to 5 and for segment 515 wasequal to 8. Accordingly, IUSC 520 can be directed to keep segment 514unscaled into Interval-4, while scaling segment 515 into segments 516and 517. IN this example embodiment, segment 512 can be scaled inresponse to determining that readers have traversed a thresholdinformation unit value, e.g., the readers are consuming sufficientlyburdening computing resources to extract information from event datathat scaling the OES can correspond to an appropriate change to thecomputing resource burden. This can occur even where there may be littleto no change in an amount of data for an event, e.g., where a DU remainsrelatively consistent but an IU has sufficient change, the OES can becorrespondingly scaled based on reader application feedback.

In another embodiment, the IU values of a segment can be determined byIUSC 520 via WPC 528 based on incoming event data comprised in write(s)506 via an analysis employing an updatable reader model, emulation,simulation, etc. This IU value can then be employed in scaling prior towriting the corresponding event data. In this embodiment, at t1, thedata for events yet to be written in Interval-1 can arrive via write(s)506, which can be analyzed by WPC 528 to generate writer applicationfeedback 508 that can indicate that IU=4 and that no scaling is needed.This can result in writing the events of Interval-1 without scaling, asillustrated in segment 512. At t2, the events yet to be written toInterval-2 can be analyzed. This can result in determining that IU=8,which is greater than the example threshold of 7, and so OES 510 can bescaled prior to writing the events into Interval-2, which scalingproximate to writing is not illustrated at 501 for clarity and brevity,although the expected scaling can result in division of segment 512 intosegments similar to 514 and 515, just at t2 rather than at t3 as isillustrated for the scaling proximate to reading events for OES 501.This can occur even where there may be little to no change in an amountof data for an event, e.g., where a DU remains relatively consistent butan IU has sufficient change, the OES can be correspondingly scaled basedon a predictive analysis of resource commitment to extract informationfrom incoming event data prior to writing the corresponding event. Insome embodiments, scaling proximate to writing events can be performedindependent of scaling proximate to reading events. While in otherembodiments, scaling proximate to writing events can be performed inconjunction with scaling proximate to reading events.

FIG. 6 is an illustration of a system 600, which can facilitate applyinga scaling policy to information-unit scaling of an OES, in accordancewith embodiments of the subject disclosure. System 600 can comprise OES610 that can store one or more OES events. OES 610 can store eventsbased on write(s) 606 received by processor component 604. OES 610 canfacilitate access to stored events as read(s) 607 via processor 604. OES610 can be stored via an OES data storage system, e.g., example system100, 300, 400, etc., on a storage component, e.g., storage component102, etc. Write(s) 606 can be received from a writer applicationinstance. A writer application instance can be embodied in componentsexternal to, but in communication with, system 600. Similarly, read(s)607 can be communicated to a reader application instance, which in someembodiments, can be embodied in components external to, but incommunication with, system 600. A writer application instance,hereinafter generally referred to as a writer, or other similar term,can be one or more writer application, e.g., a group of writerapplications can be considered a writer application instance. A readerapplication instance, herein generally referred to as a reader, or othersimilar term, can be one or more reader application, e.g., a group ofreader applications can be considered a reader application instance.

IUSC 620 can interact with processor component 604 of system 600 tofacilitate information-based scaling of OES 610 or a portion thereof.IUSC 620 can receive reader application feedback 609. Reader applicationfeedback 609 can indicate an IU metric for one or more readerapplication instances. As is noted elsewhere herein, a measurement of aburden on computing resources to enable accessing information embodiedin an event, e.g., an information-unit metric, can be distinct from ameasurement of the size of an event in terms of bits, e.g., a data-unitmetric. IUSC 620 can comprise reader performance component 629 that canenable OES scaling based on reader application feedback 609. Readerperformance component 629 can determine performance(s) of reader(s)reading from OES 610, or a portion thereof, in terms of IU metrics.Moreover, IUSC 420 can determine writer application feedback 608 basedon data to be written to an event, e.g., received via write(s) 606,wherein writer application feedback 608 can enable scaling of OES 610prior to writing the corresponding event. In this regard, IUSC 620 cancomprise writer performance component 628 that can receive event data,e.g., via a portion of event data comprised in write(s) 606, etc., andcan determine scaling of OES 610 based on the received event data priorto writing a corresponding event. Writer performance component 628 cantherefore determine an IU value for an event prior to writing the eventto OES 610. As such, OES 610 can be appropriately scaled based on thedetermined IU value prior to writing the event. Writer performancecomponent 628 can perform analysis, emulation, simulation, modeling,etc., based on updateable reader information to determine IU valuesemployable in scaling of OES 610 proximate to writing an event. In someembodiments, reader application feedback 609 can indicate which readers,or which types of readers, are reading events from OES 610, and theindication can be employed by writer performance component 628 to selectan appropriate model, emulation, simulation, etc., upon which to performincoming event analysis in relation to scaling OES 610. Moreover, in anembodiment, WPC 628 can perform OES scaling proximate to writing eventsand RPC 629 can provide supplemental scaling proximate to readingevents.

IUSC 620 can comprise scaling policy component 622 that can receivescaling policy input 623. Scaling policy component 622 can determineunder what conditions to permit or allow scaling in accord with receivedscaling policy input 623. As an example, a customer can indicate thatspecific reader instance is controlling in regard to OES IU-basedscaling. In this example, the RPC 629 and/or WPC 628 initiated scalingof OES 610 can be controlled by IU values of the specified readerinstance. In another example, scaling policy input 623 can indicate thatscaling up is permitted where at least one reader instance indicatesscaling up of an OES and that scaling down is permitted where all readerinstances indicate scaling down of the OES. In this example, OES 610 canbe scaled up when any reader indicates that the IU has transitioned athreshold value, e.g., where even one reader can be overburdened,scaling the OES can be permitted to provide relief. Moreover, in thisexample, where not all readers indicated that they can scale down, thiscan indicate that at least one of the readers would be overburdened by ascaling down and the scaling down event can be prohibited until allreaders indicate that scaling down is appropriate. Readers can indicateIU values via reader application feedback 609 that can be employed byscaling policy component 622 in conjunction with scaling policy input623 in determining permission for IUSC 620 to indicate scaling up and/orscaling down of OES 610. Scaling policy considerations can readily applyto scaling proximate to reading events, but can also apply to scalingproximate to writing events, e.g., where modeling of predicted readersindicates that IUs would remain beyond a threshold, then scaling downcan be restricted, etc. In all embodiments disclosed herein, heuristicscan be applied to scaling events, e.g., scaling up and scaling down canoccur in relation to different threshold values, IUs can be required totransition a threshold value for a designated period of time beforescaling is permitted, or numerous other rules can be applied to limit orprevent rapid oscillation of OES segment counts, e.g., preventing rapidscale up then scale down then scale up sequence can be achieved vianearly any appropriate application of one or more heuristic techniques.

In view of the example system(s) described above, example method(s) thatcan be implemented in accordance with the disclosed subject matter canbe better appreciated with reference to flowcharts in FIG. 7-FIG. 8. Forpurposes of simplicity of explanation, example methods disclosed hereinare presented and described as a series of acts; however, it is to beunderstood and appreciated that the claimed subject matter is notlimited by the order of acts, as some acts may occur in different ordersand/or concurrently with other acts from that shown and describedherein. For example, one or more example methods disclosed herein couldalternately be represented as a series of interrelated states or events,such as in a state diagram. Moreover, interaction diagram(s) mayrepresent methods in accordance with the disclosed subject matter whendisparate entities enact disparate portions of the methods. Furthermore,not all illustrated acts may be required to implement a describedexample method in accordance with the subject specification. Furtheryet, two or more of the disclosed example methods can be implemented incombination with each other, to accomplish one or more embodimentsherein described. It should be further appreciated that the examplemethods disclosed throughout the subject specification are capable ofbeing stored on an article of manufacture (e.g., a computer-readablemedium) to allow transporting and transferring such methods to computersfor execution, and thus implementation, by a processor or for storage ina memory.

FIG. 7 is an illustration of an example method 700, facilitatinginformation-unit scaling of an OES, in accordance with embodiments ofthe subject disclosure. At 710, method 700 can comprise receiving anindication of an amount of computing resources being consumed by areader application instance in relation to reading events from anordered event stream. In this regard, the amount of computing resourcesbeing consumed can relate to accessing information embodied in the dataof the stream event. This can be contrasted with an amount of computingresources consumed to merely read the data comprising the event itself.As an example, information can be encoded into an amount of data suchthat accessing the information can comprise reading the data and thendecoding the data into the information. In this regard, the amount ofcomputing resources employed to access the information embodied in thedata can be different from an amount of computing resources employed tomerely read, but not decode, the data itself. Moreover, the same datacan produce different information based on undergoing a different dataanalysis, whereby a first data analysis can employ a different amount ofcomputing resources than a second data analysis. As an example,extracting an average pixel intensity value from an image file canconsume a different amount of computing resources than determining acount of faces comprised in the image represented by the image file,which can be a different amount of computing resources than can beemployed in determining an identity of a face comprised in an image forthe image file. As such, the reader application instance, which can bedistinct from, but in communication with, the stream data storage systemcan consume different amounts of computing resources based oninformation being extracted from the actual stored bits of the streamevent data. Accordingly, the OES can be scaled to provide scaledsegments of the OES to reader instances in a manner that can reflect theburden that information extraction is placing on a reader application,e.g., where a reader becomes burdened by extracting information fromdata, then the OES can be scaled to allow the reader instance to extractdata from fewer events and/or additional reader instances can be addedto read scaled segments for information extraction, thereby reducing theburden.

At 720, method 700 can comprise determining an IU value based on theindication of the amount of computing resources being consumed by thereader application instance. In an embodiment, the IU value can reflecthow burdened the reader is, e.g., not only how many computing resourcesare being consumed, but how many are being consumed in relation to howmany are available, or some other threshold value. As an example, an IUvalue for a smartphone to extract information from an event can besubstantially different from an IU value for a supercomputer performingthe same task even though both the smartphone and the supercomputer areconsuming a same, or similar, amount of computing resources, e.g., theburden can be expected to be significantly higher for the smartphonethan for the supercomputer which can have many more computing resourcesavailable to it than would typically be available to the smartphone. Inthis regard, the information-unit metric can enable normalizing theconsumption of computing resources so that the burdening of differentreader instances can be effectively compared.

Method 700, at 730, can comprise determining an alternative OES topologyin response to the IU value being determined to satisfy a scaling rule.The scaling rule can correspond to a reader indicating transitioning athreshold IU value. In this regard, an uptick in an IU value can be toosmall to trigger a scaling event, e.g., while more resources can beemployed, those resources may not be sufficiently demanding to warrantcausing a scaling event. Further, heuristics can be incorporated intothe satisfaction of the scaling rule at 730, e.g., an uptick in IU valuemay need to exist for a designated period before the scaling rule can besatisfied.

At 740 of method 700, scaling of the OES can be initiated in response todetermining that the scaling is permissible. The scaling can be inaccord with the alternate OES topology determined at 730. At this pointmethod 700 can end. In some embodiments, even where scaling can bedesirable and an alternate OES topology can have been determined, thescaling itself can remain unpermitted. As a first example, when scalingdown an OES, permission can be attained in response to all readerinstances indicating a scaling down, e.g., less than all readersindicating scaling down can result in an unpermitted condition. As asecond example, a first reader application can be designated ascontrolling in regard to scaling an OES, whereby a second readerindicating scaling up would not be associated with permission toinitiate the scaling event, but where the first reader indicatesscaling, such scaling would be permitted.

FIG. 8 is an illustration of an example method 800, which can enableapplication of writer feedback to information-unit scaling of an OES, inaccordance with embodiments of the subject disclosure. Method 800 cancomprise, at 810, predicting an amount of computing resources that wouldbe consumed by a reader application instance when reading the from theordered event stream. The predicting can be in response to receivingevent data targeted for storage via an ordered event stream, e.g., eventdata comprised in write(s) 106, 306, 406, 506, 606, etc. A prediction ofthe amount of computing resources that would be consumed can be based onthe received event data and an analysis of a model of a reader,emulation of a reader, simulation of a reader, or other predictivemechanism. In this regard, the amount of computing resources that wouldbe consumed can be predicted, and the prediction can correlate to futurereader application accessing information from the data once written intoan event of the OES. As elsewhere herein, an amount of computingresources employed in accessing information embodied in event data andan amount of event data itself can be different measurements.

At 820, method 800 can comprise determining an IU value based on thepredicted amount of computing resources that would be consumed by thereader application instance. In an embodiment, the IU value can reflecthow burdened the reader is, e.g., not only how many computing resourcesare being consumed, but how many are being consumed in relation to howmany are available, or some other threshold value. It is noted that morethan one IU value can be determined where more than one model of readerapplication, more than one information result, or some combinationthereof is presented. As an example, determining a count of persons inan image can have a first IU value and determining an identity ofpersons in an image can have a different IU value. To this end,selection of a reader model, emulation, simulation, etc., can be morehighly refined than presented herein, although all such reader selectiontechniques are considered within the scope of the instant disclosurewhere they lead to determining one or more IU values. Theinformation-unit metric can enable normalizing the consumption ofcomputing resources so that the burdening of different reader instancescan be effectively compared.

Method 800, at 830, can comprise determining an alternative OES topologyin response to the IU value being determined to satisfy a scaling rule.The scaling rule can correspond to a reader indicating transitioning athreshold IU value. In this regard, an uptick in an IU value can be toosmall to trigger a scaling event, e.g., while more resources can beemployed, those resources may not be sufficiently demanding to warrantcausing a scaling event. Further, heuristics can be incorporated intothe satisfaction of the scaling rule at 830, e.g., an uptick in IU valuemay be enforced to exist for a designated period before the scaling rulecan be satisfied.

At 840 of method 800, scaling of the OES can be initiated in response todetermining that the scaling is permissible. The scaling can be inaccord with the alternate OES topology determined at 830. An event canbe written to the OES after the corresponding scaling is completed. Atthis point method 800 can end. In some embodiments, the illustratescaling proximate to writing an event can be further coupled withsubsequent scaling proximate to reading an event. In these embodiments,even where the prediction at 810 can be imperfect, resulting in scalingthat can be less than optimal at 840, the performance of actual readersupon reading the OES after 840 can rely on methods like that presentedat method 700, to further correctively scale the OES and can thereforecompensate for less than perfect predictions at 810.

FIG. 9 is a schematic block diagram of a computing environment 900 withwhich the disclosed subject matter can interact. The system 900comprises one or more remote component(s) 910. The remote component(s)910 can be hardware and/or software (e.g., threads, processes, computingdevices). In some embodiments, remote component(s) 910 can be a remotelylocated device comprised in storage component 102, etc., a remotelylocated processor device comprised in processor component 104, 304, 404,504, 604, etc., a remotely located device comprised in IUSC 120, 320,420, 520, 620, etc., reader performance component 329, 529, 629, etc.,writer performance component 428, 528, 628, etc., scaling policycomponent 622, etc., or other remotely located components connected to alocal component via communication framework 990. Communication framework990 can comprise wired network devices, wireless network devices, mobiledevices, wearable devices, radio access network devices, gatewaydevices, femtocell devices, servers, etc.

The system 900 also comprises one or more local component(s) 920. Thelocal component(s) 920 can be hardware and/or software (e.g., threads,processes, computing devices). In some embodiments, local component(s)920 can comprise storage component 102, etc., a locally locatedprocessor device comprised in processor component 104, 304, 404, 504,604, etc., a locally located device comprised in IUSC 120, 320, 420,520, 620, etc., reader performance component 329, 529, 629, etc., writerperformance component 428, 528, 628, etc., scaling policy component 622,etc., or other local components connected to a local component viacommunication framework 990.

One possible communication between a remote component(s) 910 and a localcomponent(s) 920 can be in the form of a data packet adapted to betransmitted between two or more computer processes. Another possiblecommunication between a remote component(s) 910 and a local component(s)920 can be in the form of circuit-switched data adapted to betransmitted between two or more computer processes in radio time slots.The system 900 comprises a communication framework 990 that can beemployed to facilitate communications between the remote component(s)910 and the local component(s) 920, and can comprise an air interface,e.g., Uu interface of a UMTS network, via a long-term evolution (LTE)network, etc. Remote component(s) 910 can be operably connected to oneor more remote data store(s) 950, such as a hard drive, solid statedrive, SIM card, device memory, etc., that can be employed to storeinformation on the remote component(s) 910 side of communicationframework 990. Similarly, local component(s) 920 can be operablyconnected to one or more local data store(s) 930, that can be employedto store information on the local component(s) 920 side of communicationframework 990. As examples, OES scaling data can be communicated from aremotely located component, e.g., IUSC 120, 320, 420, 520, 620, etc.,via communication framework 990, to a local component, e.g., processorcomponent 104, 304, 4040, 504, 604, etc., to facilitate scaling an OES,as disclosed herein.

In order to provide a context for the various embodiments of thedisclosed subject matter, FIG. 10, and the following discussion, areintended to provide a brief, general description of a suitableenvironment in which the various embodiments of the disclosed subjectmatter can be implemented. While the subject matter has been describedabove in the general context of computer-executable instructions of acomputer program that runs on a computer and/or computers, those skilledin the art will recognize that the disclosed subject matter also can beimplemented in combination with other program modules. Generally,program modules comprise routines, programs, components, datastructures, etc. that performs particular tasks and/or implementparticular abstract data types.

In the subject specification, terms such as “store,” “storage,” “datastore,” data storage,” “database,” and substantially any otherinformation storage component relevant to operation and functionality ofa component, refer to “memory components,” or entities embodied in a“memory” or components comprising the memory. It is noted that thememory components described herein can be either volatile memory ornonvolatile memory, or can comprise both volatile and nonvolatilememory, by way of illustration, and not limitation, volatile memory 1020(see below), non-volatile memory 1022 (see below), disk storage 1024(see below), and memory storage 1046 (see below). Further, nonvolatilememory can be included in read only memory, programmable read onlymemory, electrically programmable read only memory, electricallyerasable read only memory, or flash memory. Volatile memory can compriserandom access memory, which acts as external cache memory. By way ofillustration and not limitation, random access memory is available inmany forms such as synchronous random access memory, dynamic randomaccess memory, synchronous dynamic random access memory, double datarate synchronous dynamic random access memory, enhanced synchronousdynamic random access memory, SynchLink dynamic random access memory,and direct Rambus random access memory. Additionally, the disclosedmemory components of systems or methods herein are intended to comprise,without being limited to comprising, these and any other suitable typesof memory.

Moreover, it is noted that the disclosed subject matter can be practicedwith other computer system configurations, comprising single-processoror multiprocessor computer systems, mini-computing devices, mainframecomputers, as well as personal computers, hand-held computing devices(e.g., personal digital assistant, phone, watch, tablet computers,netbook computers, . . . ), microprocessor-based or programmableconsumer or industrial electronics, and the like. The illustratedembodiments can also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network; however, some if not all features ofthe subject disclosure can be practiced on stand-alone computers. In adistributed computing environment, program modules can be located inboth local and remote memory storage devices.

FIG. 10 illustrates a block diagram of a computing system 1000 operableto execute the disclosed systems and methods in accordance with anembodiment. Computer 1012, which can be, for example, comprised in anyof storage component 102, etc., processor component 104, 304, 404, 504,604, etc., IUSC 120, 320, 420, 520, 620, etc., reader performancecomponent 329, 529, 629, etc., writer performance component 428, 528,628, etc., scaling policy component 622, etc., or other componentsdisclosed herein, can comprise a processing unit 1014, a system memory1016, and a system bus 1018. System bus 1018 can couple systemcomponents comprising, but not limited to, system memory 1016 toprocessing unit 1014. Processing unit 1014 can be any of variousavailable processors. Dual microprocessors and other multiprocessorarchitectures also can be employed as processing unit 1014.

System bus 1018 can be any of several types of bus structure(s)comprising a memory bus or a memory controller, a peripheral bus or anexternal bus, and/or a local bus using any variety of available busarchitectures comprising, but not limited to, industrial standardarchitecture, micro-channel architecture, extended industrial standardarchitecture, intelligent drive electronics, video electronics standardsassociation local bus, peripheral component interconnect, card bus,universal serial bus, advanced graphics port, personal computer memorycard international association bus, Firewire (Institute of Electricaland Electronics Engineers 1194), and small computer systems interface.

System memory 1016 can comprise volatile memory 1020 and nonvolatilememory 1022. A basic input/output system, containing routines totransfer information between elements within computer 1012, such asduring start-up, can be stored in nonvolatile memory 1022. By way ofillustration, and not limitation, nonvolatile memory 1022 can compriseread only memory, programmable read only memory, electricallyprogrammable read only memory, electrically erasable read only memory,or flash memory. Volatile memory 1020 comprises read only memory, whichacts as external cache memory. By way of illustration and notlimitation, read only memory is available in many forms such assynchronous random access memory, dynamic read only memory, synchronousdynamic read only memory, double data rate synchronous dynamic read onlymemory, enhanced synchronous dynamic read only memory, SynchLink dynamicread only memory, Rambus direct read only memory, direct Rambus dynamicread only memory, and Rambus dynamic read only memory.

Computer 1012 can also comprise removable/non-removable,volatile/non-volatile computer storage media. FIG. 10 illustrates, forexample, disk storage 1024. Disk storage 1024 comprises, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, flash memory card, or memory stick. In addition, disk storage1024 can comprise storage media separately or in combination with otherstorage media comprising, but not limited to, an optical disk drive suchas a compact disk read only memory device, compact disk recordabledrive, compact disk rewritable drive or a digital versatile disk readonly memory. To facilitate connection of the disk storage devices 1024to system bus 1018, a removable or non-removable interface is typicallyused, such as interface 1026.

Computing devices typically comprise a variety of media, which cancomprise computer-readable storage media or communications media, whichtwo terms are used herein differently from one another as follows.

Computer-readable storage media can be any available storage media thatcan be accessed by the computer and comprises both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable storage media can be implementedin connection with any method or technology for storage of informationsuch as computer-readable instructions, program modules, structureddata, or unstructured data. Computer-readable storage media cancomprise, but are not limited to, read only memory, programmable readonly memory, electrically programmable read only memory, electricallyerasable read only memory, flash memory or other memory technology,compact disk read only memory, digital versatile disk or other opticaldisk storage, magnetic cassettes, magnetic tape, magnetic disk storageor other magnetic storage devices, or other tangible media which can beused to store desired information. In this regard, the term “tangible”herein as may be applied to storage, memory or computer-readable media,is to be understood to exclude only propagating intangible signals perse as a modifier and does not relinquish coverage of all standardstorage, memory or computer-readable media that are not only propagatingintangible signals per se. In an embodiment, tangible media can comprisenon-transitory media wherein the term “non-transitory” herein as may beapplied to storage, memory or computer-readable media, is to beunderstood to exclude only propagating transitory signals per se as amodifier and does not relinquish coverage of all standard storage,memory or computer-readable media that are not only propagatingtransitory signals per se. Computer-readable storage media can beaccessed by one or more local or remote computing devices, e.g., viaaccess requests, queries or other data retrieval protocols, for avariety of operations with respect to the information stored by themedium. As such, for example, a computer-readable medium can compriseexecutable instructions stored thereon that, in response to execution,can cause a system comprising a processor to perform operationscomprising determining a normalized value indicating a level of burdenon computing resources corresponding to accessing information embodiedin event data of an ordered event stream event, e.g., an IU value.Moreover, in response to determining that a scaling rule has beensatisfied based on the normalized value, e.g., the IU value transitionsa threshold value, determining an updated topology for the ordered eventstream to support scaling the OES. The scaling of the OES can then beperformed, where permissible to adapt the OES topology based on thelevel of computing resource burden indicated via the IU value.

Communications media typically embody computer-readable instructions,data structures, program modules or other structured or unstructureddata in a data signal such as a modulated data signal, e.g., a carrierwave or other transport mechanism, and comprises any informationdelivery or transport media. The term “modulated data signal” or signalsrefers to a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in one or moresignals. By way of example, and not limitation, communication mediacomprise wired media, such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media.

It can be noted that FIG. 10 describes software that acts as anintermediary between users and computer resources described in suitableoperating environment 1000. Such software comprises an operating system1028. Operating system 1028, which can be stored on disk storage 1024,acts to control and allocate resources of computer system 1012. Systemapplications 1030 take advantage of the management of resources byoperating system 1028 through program modules 1032 and program data 1034stored either in system memory 1016 or on disk storage 1024. It is to benoted that the disclosed subject matter can be implemented with variousoperating systems or combinations of operating systems.

A user can enter commands or information into computer 1012 throughinput device(s) 1036. In some embodiments, a user interface can allowentry of user preference information, etc., and can be embodied in atouch sensitive display panel, a mouse/pointer input to a graphical userinterface (GUI), a command line controlled interface, etc., allowing auser to interact with computer 1012. Input devices 1036 comprise, butare not limited to, a pointing device such as a mouse, trackball,stylus, touch pad, keyboard, microphone, joystick, game pad, satellitedish, scanner, TV tuner card, digital camera, digital video camera, webcamera, cell phone, smartphone, tablet computer, etc. These and otherinput devices connect to processing unit 1014 through system bus 1018 byway of interface port(s) 1038. Interface port(s) 1038 comprise, forexample, a serial port, a parallel port, a game port, a universal serialbus, an infrared port, a Bluetooth port, an IP port, or a logical portassociated with a wireless service, etc. Output device(s) 1040 use someof the same type of ports as input device(s) 1036.

Thus, for example, a universal serial bus port can be used to provideinput to computer 1012 and to output information from computer 1012 toan output device 1040. Output adapter 1042 is provided to illustratethat there are some output devices 1040 like monitors, speakers, andprinters, among other output devices 1040, which use special adapters.Output adapters 1042 comprise, by way of illustration and notlimitation, video and sound cards that provide means of connectionbetween output device 1040 and system bus 1018. It should be noted thatother devices and/or systems of devices provide both input and outputcapabilities such as remote computer(s) 1044.

Computer 1012 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)1044. Remote computer(s) 1044 can be a personal computer, a server, arouter, a network PC, cloud storage, a cloud service, code executing ina cloud-computing environment, a workstation, a microprocessor-basedappliance, a peer device, or other common network node and the like, andtypically comprises many or all of the elements described relative tocomputer 1012. A cloud computing environment, the cloud, or othersimilar terms can refer to computing that can share processing resourcesand data to one or more computer and/or other device(s) on an as neededbasis to enable access to a shared pool of configurable computingresources that can be provisioned and released readily. Cloud computingand storage solutions can store and/or process data in third-party datacenters which can leverage an economy of scale and can view accessingcomputing resources via a cloud service in a manner similar to asubscribing to an electric utility to access electrical energy, atelephone utility to access telephonic services, etc.

For purposes of brevity, only a memory storage device 1046 isillustrated with remote computer(s) 1044. Remote computer(s) 1044 islogically connected to computer 1012 through a network interface 1048and then physically connected by way of communication connection 1050.Network interface 1048 encompasses wire and/or wireless communicationnetworks such as local area networks and wide area networks. Local areanetwork technologies comprise fiber distributed data interface, copperdistributed data interface, Ethernet, Token Ring and the like. Wide areanetwork technologies comprise, but are not limited to, point-to-pointlinks, circuit-switching networks like integrated services digitalnetworks and variations thereon, packet switching networks, and digitalsubscriber lines. As noted below, wireless technologies may be used inaddition to or in place of the foregoing.

Communication connection(s) 1050 refer(s) to hardware/software employedto connect network interface 1048 to bus 1018. While communicationconnection 1050 is shown for illustrative clarity inside computer 1012,it can also be external to computer 1012. The hardware/software forconnection to network interface 1048 can comprise, for example, internaland external technologies such as modems, comprising regular telephonegrade modems, cable modems and digital subscriber line modems,integrated services digital network adapters, and Ethernet cards.

The above description of illustrated embodiments of the subjectdisclosure, comprising what is described in the Abstract, is notintended to be exhaustive or to limit the disclosed embodiments to theprecise forms disclosed. While specific embodiments and examples aredescribed herein for illustrative purposes, various modifications arepossible that are considered within the scope of such embodiments andexamples, as those skilled in the relevant art can recognize.

In this regard, while the disclosed subject matter has been described inconnection with various embodiments and corresponding Figures, whereapplicable, it is to be understood that other similar embodiments can beused or modifications and additions can be made to the describedembodiments for performing the same, similar, alternative, or substitutefunction of the disclosed subject matter without deviating therefrom.Therefore, the disclosed subject matter should not be limited to anysingle embodiment described herein, but rather should be construed inbreadth and scope in accordance with the appended claims below.

As it employed in the subject specification, the term “processor” canrefer to substantially any computing processing unit or devicecomprising, but not limited to comprising, single-core processors;single-processors with software multithread execution capability;multi-core processors; multi-core processors with software multithreadexecution capability; multi-core processors with hardware multithreadtechnology; parallel platforms; and parallel platforms with distributedshared memory. Additionally, a processor can refer to an integratedcircuit, an application specific integrated circuit, a digital signalprocessor, a field programmable gate array, a programmable logiccontroller, a complex programmable logic device, a discrete gate ortransistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Processorscan exploit nano-scale architectures such as, but not limited to,molecular and quantum-dot based transistors, switches and gates, inorder to optimize space usage or enhance performance of user equipment.A processor may also be implemented as a combination of computingprocessing units.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “selector,” “interface,” and the like are intendedto refer to a computer-related entity or an entity related to anoperational apparatus with one or more specific functionalities, whereinthe entity can be either hardware, a combination of hardware andsoftware, software, or software in execution. As an example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration and not limitation, both anapplication running on a server and the server can be a component. Oneor more components may reside within a process and/or thread ofexecution and a component may be localized on one computer and/ordistributed between two or more computers. In addition, these componentscan execute from various computer readable media having various datastructures stored thereon. The components may communicate via localand/or remote processes such as in accordance with a signal having oneor more data packets (e.g., data from one component interacting withanother component in a local system, distributed system, and/or across anetwork such as the Internet with other systems via the signal). Asanother example, a component can be an apparatus with specificfunctionality provided by mechanical parts operated by electric orelectronic circuitry, which is operated by a software or a firmwareapplication executed by a processor, wherein the processor can beinternal or external to the apparatus and executes at least a part ofthe software or firmware application. As yet another example, acomponent can be an apparatus that provides specific functionalitythrough electronic components without mechanical parts, the electroniccomponents can comprise a processor therein to execute software orfirmware that confers at least in part the functionality of theelectronic components.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom context, “X employs A or B” is intended to mean any of the naturalinclusive permutations. That is, if X employs A; X employs B; or Xemploys both A and B, then “X employs A or B” is satisfied under any ofthe foregoing instances. Moreover, articles “a” and “an” as used in thesubject specification and annexed drawings should generally be construedto mean “one or more” unless specified otherwise or clear from contextto be directed to a singular form. Moreover, the use of any particularembodiment or example in the present disclosure should not be treated asexclusive of any other particular embodiment or example, unlessexpressly indicated as such, e.g., a first embodiment that hascharacteristic A and a second embodiment that has characteristic B doesnot preclude a third embodiment that has characteristic A andcharacteristic B. The use of granular examples and embodiments isintended to simplify understanding of certain features, characteristics,etc., of the disclosed subject matter and is not intended to limit thedisclosure to said granular instances of the disclosed subject matter orto illustrate that combinations of embodiments of the disclosed subjectmatter were not contemplated at the time of actual or constructivereduction to practice.

Further, the term “include” is intended to be employed as an open orinclusive term, rather than a closed or exclusive term. The term“include” can be substituted with the term “comprising” and is to betreated with similar scope, unless otherwise explicitly used otherwise.As an example, “a basket of fruit including an apple” is to be treatedwith the same breadth of scope as, “a basket of fruit comprising anapple.”

Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,”“prosumer,” “agent,” and the like are employed interchangeablythroughout the subject specification, unless context warrants particulardistinction(s) among the terms. It should be appreciated that such termscan refer to human entities, machine learning components, or automatedcomponents (e.g., supported through artificial intelligence, as througha capacity to make inferences based on complex mathematical formalisms),that can provide simulated vision, sound recognition and so forth.

Characteristics, features, or advantages of the subject matter can beexploited in substantially any, or any, wired, broadcast, wirelesstelecommunication, radio technology or network, or combinations thereof.Non-limiting examples of such technologies or networks comprisebroadcast technologies (e.g., sub-Hertz, extremely low frequency, verylow frequency, low frequency, medium frequency, high frequency, veryhigh frequency, ultra-high frequency, super-high frequency, extremelyhigh frequency, terahertz broadcasts, etc.); Ethernet; X.25;powerline-type networking, e.g., Powerline audio video Ethernet, etc.;femtocell technology; Wi-Fi; worldwide interoperability for microwaveaccess; enhanced general packet radio service; second generationpartnership project (2G or 2GPP); third generation partnership project(3G or 3GPP); fourth generation partnership project (4G or 4GPP); longterm evolution (LTE); fifth generation partnership project (5G or 5GPP);third generation partnership project universal mobile telecommunicationssystem; third generation partnership project 2; ultra mobile broadband;high speed packet access; high speed downlink packet access; high speeduplink packet access; enhanced data rates for global system for mobilecommunication evolution radio access network; universal mobiletelecommunications system terrestrial radio access network; or long termevolution advanced. As an example, a millimeter wave broadcasttechnology can employ electromagnetic waves in the frequency spectrumfrom about 30 GHz to about 300 GHz. These millimeter waves can begenerally situated between microwaves (from about 1 GHz to about 30 GHz)and infrared (IR) waves, and are sometimes referred to extremely highfrequency (EHF). The wavelength (λ) for millimeter waves is typically inthe 1-mm to 10-mm range.

The term “infer,” or “inference,” can generally refer to the process ofreasoning about, or inferring states of, the system, environment, user,and/or intent from a set of observations as captured via events and/ordata. Captured data and events can include user data, device data,environment data, data from sensors, sensor data, application data,implicit data, explicit data, etc. Inference, for example, can beemployed to identify a specific context or action, or can generate aprobability distribution over states of interest based on aconsideration of data and events. Inference can also refer to techniquesemployed for composing higher-level events from a set of events and/ordata. Such inference results in the construction of new events oractions from a set of observed events and/or stored event data, whetherthe events, in some instances, can be correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources. Various classification schemes and/or systems(e.g., support vector machines, neural networks, expert systems,Bayesian belief networks, fuzzy logic, and data fusion engines) can beemployed in connection with performing automatic and/or inferred actionin connection with the disclosed subject matter.

What has been described above includes examples of systems and methodsillustrative of the disclosed subject matter. It is, of course, notpossible to describe every combination of components or methods herein.One of ordinary skill in the art may recognize that many furthercombinations and permutations of the claimed subject matter arepossible. Furthermore, to the extent that the terms “includes,” “has,”“possesses,” and the like are used in the detailed description, claims,appendices and drawings such terms are intended to be inclusive in amanner similar to the term “comprising” as “comprising” is interpretedwhen employed as a transitional word in a claim.

What is claimed is:
 1. A system, comprising: a processor; and a memorythat stores executable instructions that, when executed by theprocessor, facilitate performance of operations, comprising: determininga value indicating a level of burden on computing resourcescorresponding to accessing information embodied in event data of anordered event stream event; in response to the value being determined tohave satisfied a scaling rule related to scaling a segment of an orderedevent stream related to the ordered event stream event, determining anadaptation to a topology of a key space of the ordered event streamcorresponding to scaling the ordered event stream; and in response todetermining that a permission rule related to permitting the scaling ofthe ordered event stream to occur has been satisfied, implementingscaling of the ordered event stream in accord with the adaptation to thetopology of the key space of the ordered event stream.
 2. The system ofclaim 1, wherein the ordered event stream event has previously beenwritten to the ordered event stream, and wherein the determining thevalue is based on performance data received from a reader applicationinstance that is reading the ordered event stream event from the orderedevent stream.
 3. The system of claim 2, wherein the scaling of theordered event stream is a scaling up of the ordered event stream,wherein the value corresponds to a reader application instance of readerapplication instances, and wherein the permission rule is satisfied whenthe value is determined to have satisfied the scaling rule.
 4. Thesystem of claim 2, wherein the scaling of the ordered event stream is ascaling down of the ordered event stream, wherein the permission rule issatisfied when values for every reader application instance of readerapplication instances have been determined to satisfy the scaling rule,and wherein the reader application instances comprise the readerapplication instance.
 5. The system of claim 2, wherein the readerapplication instance is in communication with, but is not executing on,a component comprised in the system.
 6. The system of claim 1, whereinthe event data is received from a writer application instance, whereinthe ordered event stream event has not yet been written to the orderedevent stream, and wherein the determining the value is based onpredicted performance data determined from analysis of a modeled readerapplication instance and the event data.
 7. The system of claim 6,wherein the operations further comprise writing the event data as theordered event stem event to the ordered event stream after the scalingof the ordered event stream is performed and in accord with theadaptation to the topology of the key space of the ordered event stream.8. The system of claim 7, wherein the operations further compriseperforming, in response to a future event reading operation via a readerapplication instance, performing a supplemental scaling event based onfeedback from the reader application instance.
 9. The system of claim 6,wherein the writer application instance is in communication with, but isnot executing on, a component comprised in the system.
 10. The system ofclaim 1, wherein the scaling of the ordered event stream results individing the segment of the ordered event stream into at least two newsegments in the ordered event stream, resulting in the ordered eventstream comprising more segments than before the scaling.
 11. The systemof claim 1, wherein the scaling of the ordered event stream results inmerging the segment of the ordered event stream with another segment ofthe ordered event stream, resulting in the ordered event streamcomprising fewer segments than before the scaling.
 12. A method,comprising: determining, by a system comprising a processor, anormalized indicator corresponding to an amount of computing resourcesrequested to enable access to information embodied in event data of anordered event stream event; determining, by the system, that thenormalized indicator has satisfied a scaling rule related to scaling asegment of an ordered event stream related to the ordered event streamevent; determining, by the system, a scaled key space topologycorresponding to scaling the ordered event stream; determining, by thesystem, that the scaling of the segment of the ordered event stream isallowed; and facilitating, by the system, access to the scaled key spacetopology to support the scaling of the segment of the ordered eventstream.
 13. The method of claim 12, wherein the determining thenormalized indicator comprises receiving reader application instancefeedback corresponding to reading the ordered event stream event fromthe segment of the ordered event stream.
 14. The method of claim 13,wherein the reader application instance feedback is received from areader application instance that is executed via another system.
 15. Themethod of claim 12, wherein the determining the normalized indicatorcomprises: receiving, by the system, the event data from a writerapplication instance prior to writing the event data to the orderedevent stream event; and analyzing, by the system, a model of a readerapplication instance based on the event data.
 16. The method of claim15, wherein the operations further comprise enabling writing of theevent data to the ordered event stream subsequent to the scaling of thesegment of the ordered event stream.
 17. The method of claim 15, whereinthe writer application instance is executed via a system other than thesystem.
 18. A non-transitory machine-readable medium, comprisingexecutable instructions that, when executed by a processor, facilitateperformance of operations, comprising: determining a normalized valueindicating a level of burden on computing resources corresponding toaccessing information embodied in event data of an ordered event streamevent; determining that a scaling rule related to scaling a segment ofan ordered event stream related to the ordered event stream event hasbeen satisfied based on the normalized value; determining an updatedtopology for a key space of the ordered event stream, wherein theupdated topology corresponds to performing a scaling operation on theordered event stream; and enabling performance of the scaling operationon the ordered event stream resulting in a scaled ordered event streamaccording to the updated topology.
 19. The non-transitorymachine-readable medium of claim 18, wherein the ordered event streamevent was previously written to the ordered event stream, and whereinthe normalized value is determined from reader application instancefeedback corresponding to reading the ordered event stream event. 20.The non-transitory machine-readable medium of claim 18, wherein theevent data is not yet written to the ordered event stream, wherein theevent data is received from a writer application instance, wherein thenormalized value is determined from analysis of a simulation of a readerevent application instance and the event data, and wherein the eventdata is written as the ordered event stream event in response to thescaling operation having been determined to have occurred.